@encukou, I think this should fix compatibility with NumPy (buffer protocol). We can decide later what to do with _type_ (use same code or not).

I'm worried that this is a breaking change relative to Python 3.14.
It should definitely be mentioned in What's New if it gets in.

But, with #148676 this would be redundant.

Documentation build overview

📚 cpython-previews | 🛠️ Build #32526288 | 📁 Comparing 7aa47c3 against main (2ba0a81)

  🔍 Preview build  

It should definitely be mentioned in What's New if it gets in.

Done.

But, with #148676 this would be redundant.

(I think merging that pr is a bad idea.)

Though, you are right, my 3 PRs - only an alternative.

I merged my PR instead which changes ctypes _type_. This change would be an alternative if we decide later to leave _type_ unchanged and only change the used buffer format.

@vstinner, you already closed this door by #149368.

Anyway, that's a kind of direction I would like to support, instead of #148676. No multiple type codes. I only worry, that in this way you also introduce incompatibility with the NumPy.

That's why reversion of my changes in 3.15 and struct (deprecation) looks better for me. Lets wait decision on a PEP. Then extend the struct module in The Right Way. Then adapt other stuff. This PR does make sense only on this kind of road.